This chapter provides information for monitoring service status and performance using the show commands found in the Command Line Interface (CLI). These command have many related keywords that allow them to provide useful information on all aspects of the system ranging from current software configuration through call activity and status.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dns-client query client-name client_name query-type AAAA query-name <p-cscf.com>
|
|
|
|
|
|
|
context egress_pgw_context_name
|
|
|
context ingress_pgw_context_name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
context egress_pgw_context_name
|
|
|
context egress_pgw_context_name
|
|
|
|
|
|
|
|
|
|
|
|
|
context ingress_pgw_context_name
|
|
|
|
|
|
|
|
|
|
|
|
|
Important: Refer to the System Software Task and Subsystem Descriptions appendix in the System Administration Guide for additional information on the Session subsystem and its various manager tasks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Statistics and counters can be cleared using the CLI clear command. Refer to the Command
Line Reference for detailed information on using this command.
Important: Direct tunnel is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
The direct tunnel architecture allows the establishment of a direct user plane (GTP-U) tunnel between the radio access network equipment (RNC) and the GGSN/P-GW.
Once a direct tunnel is established, the SGSN/S-GW continues to handle the control plane (RANAP/GTP-C) signaling and retains the responsibility of making the decision to establish direct tunnel at PDN context activation.
|
•
|
3G network: The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN, using an Updated PDN Context Request toward the GGSN.
|
|
•
|
LTE network: When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality. The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN/P-GW, using an Update PDN Context Request toward the GGSN/P-GW.
|
|
•
|
LTE network: The SGSN establishes a user plane tunnel (GTP-U tunnel over an S12 interface) directly between the RNC and the S-GW, using an Update PDN Context Request toward the S-GW.
|
Important: If direct tunnel is allowed in the
default operator policy, then any incoming call that does not have an applicable operator policy configured will have direct tunnel
allowed.
Before beginning any of the following procedures, you must have completed (1) the basic service configuration for the SGSN, as described in the Cisco ASR Serving GPRS Support Node Administration Guide, and (2) the creation and configuration of a valid operator policy, as described in the
Operator Policy chapter in this guide.
Important: It is only necessary to complete either step 2 or step 3 as a direct tunnel can not be setup on the basis of call filtering matched with both an APN profile and an IIMEI profile.
|
Step 5
|
(Optional) Configure the SGSN to disallow direct tunnel setup to a single GGSN that has been configured to allow it in the APN profile. This command allows the operator to restrict use of a GGSN for any reason, such as load balancing. Refer to the direct-tunnel-disabled-ggsn command in the SGTP Service Configuration Mode chapter of the Command Line Interface Reference.
|
By default, APN-based direct tunnel functionality is allowed so any existing direct tunnel configuration must be removed to return to default and to ensure that the setup has not been restricted.
Important: GRE protocol interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
Important: This section provides the minimum instruction set to enable the GRE Protocol Interface support functionality on a GGSN or P-GW. Commands that configure additional functions for this feature are provided in the Command
Line Interface Reference.
context <vpn_context_name> -noconfirm ]
|
•
|
<vpn_context_name> is the name of the system context you want to use for VRF. For more information, refer System Administration Guide.
|
|
•
|
<vrf_name> is name of the VRF which is to be associated with various interfaces.
|
|
•
|
<vpn_context_name> is the name of the system context you want to use for GRE interface configuration. For more information, refer Command Line Interface Reference.
|
|
•
|
<intfc_name> is name of the IP interface which is defined as a tunnel type interface and to be used for GRE tunnel interface.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for VRF forwarding.
|
|
•
|
<non_tunn_intfc_to_corp> is the name a non-tunnel interface which is required by system as source interface and preconfigured. For more information on interface configuration refer System Administration Guide.
|
|
•
|
<global_ip_address> is a globally reachable IP address to be used as a destination address.
|
|
•
|
<vpn_context_name> is the name of the system context you want to use for OSPF routing. For more information, refer Routing in this guide.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for OSPF routing.
|
ip pool <ip_pool_name> <
internal_ip_address/mask> vrf <
vrf_name>
|
•
|
<vpn_context_name> is the name of the system context you want to use for IP pool and AAA server group.
|
|
•
|
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
|
|
•
|
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for IP pool.
|
|
•
|
<vpn_context_name> is the name of the system context you want to use for APN configuration.
|
|
•
|
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
|
|
•
|
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
ip route <internal_ip_address/mask> tunnel <
tunnel_intfc_name> vrf <
vrf_name>
|
•
|
<vpn_context_name> is the name of the system context you want to use for static route configuration.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used as static route.
|
|
•
|
<tunnel_intfc_name> is name of a predefined tunnel type IP interface which is to be used for GRE tunnel interface.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
Important: In addition to standard Gx interface functionality, the Gx interface implemented here provides support of SBLP with additional AVPs in custom DPCA dictionaries. For more information on customer-specific support contact your local technical support representative. In view of required flow bandwidth and QoS, the system provides enhanced support for use of Service Based Local Policy (SBLP) to provision and control the resources used by the IMS subscriber. SBLP is based on the dynamic parameters such as the media/traffic flows for data transport, network conditions and static parameters, such as subscriber configuration and category. It also provides Flow-based Charging (FBC) mechanism to charge the subscriber dynamically based on content usage. With this additional functionality, the Cisco Systems Gateway can act as an Enhanced Policy Decision Function (E-PDF).
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
|
•
|
<context_name> must be the name of the context where you want to enable IMS Authorization Service.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization Service to be configured for the Gx interface authentication.
|
|
•
|
Optional: To configure the quality of service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
|
qos-update-timeout <timeout_duration>
|
•
|
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
|
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
|
•
|
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
|
|
•
|
Optional: To configure the algorithm to select Diameter host table, in the Policy Control Configuration Mode, enter the following command:
|
|
•
|
<context_name> must be the name of the context in which the IMS Authorization service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication in the context.
|
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication.
|
•
|
Binding: Binding is the generation of an association between a Service Data Flow (SDF) and the IP CAN bearer (for GPRS a PDP context) transporting that SDF.
|
|
•
|
Gating Control: Gating control is the blocking or allowing of packets, belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is opened, the packets of the related IP flows are allowed to be forwarded.
|
|
•
|
Event Reporting: Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF).
|
Important: In this release, event triggers “IP-CAN_CHANGE” and “MAX_NR_BEARERS_REACHED” are not supported.
|
•
|
QoS Control: QoS control is the authorization and enforcement of the maximum QoS that is authorized for a SDF or an IP-CAN bearer or a QoS Class Identifier (QCI). In case of an aggregation of multiple SDFs (for GPRS a PDP context), the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate.
|
Important: In this release, QoS Resource Reservation is not supported.
Important: In this release, coordination of authorized QoS scopes in mixed mode (BCM = UE_NW) is not supported.
Important: In 11.0 and later releases, Rule-Activation-Time / Rule-Deactivation-Time / Revalidation-Time AVP is successfully parsed only if its value corresponds to current time or a later time than the current IPSG time, else the AVP and entire message is rejected. In earlier releases the AVP is successfully parsed only if its value corresponds to a later time than the current IPSG time, else the AVP and entire message is rejected.
Important: In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Important: A third type of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
Important: In earlier releases, ECS used only the Priority-Level part of ARP byte for bearer binding, (along with QCI). Now the entire ARP byte is used for bearer binding (along with QCI). Since the capability and vulnerability bits are optional in a dynamic rule, if a dynamic rule is received without these flags, it is assumed that the capability bit is set to 1 (disabled) and vulnerability bit is set to 0 (enabled). For predefined rules, currently configuring these two flags is not supported, so as of now all predefined rules are assumed to have capability bit set to 1 (disabled) and vulnerability bit set to 0 (enabled).
Important: In this release, configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
Important: In 11.0 and later releases, the maximum valid length for a charging rule name is 63 bytes. When the length of the charging rule name is greater than 63 bytes, a charging rule report with RESOURCES_LIMITATION as Rule-Failure-Code is sent. This charging rule report is sent only when the length of the rule name is lesser than 128 characters. When the charging rule name length is greater than or equal to 128 characters no charging rule report will be sent. In earlier releases, the length of the charging rule name constructed by PCRF was limited to 32 bytes.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
Important: In 11.0 and later releases, IMSA and ECS allow the PCRF to install two (or more) dynamic rules with the same precedence value. In earlier releases, for two distinct dynamic rules having the same precedence the second rule used to be rejected.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
diameter host-select row-precedence <precedence_value> table { { { 1 | 2 } host <host_name> [ realm <realm_id> ] [ secondary host <host_name> [ realm <realm_id> ] ] } | { prefix-table { 1 | 2 } msisdn-prefix-from <msisdn_prefix_from> msisdn-prefix-to <msisdn_prefix_to> host <host_name> [ realm <realm_id> ] [ secondary host <sec_host_name> [ realm <sec_realm_id> ] algorithm { active-standby | round-robin } ] } } [ -noconfirm ]
|
•
|
<context_name> must be the name of the context where you want to enable IMS Authorization service.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization service to be configured for Rel. 7 Gx interface authentication.
|
To enable the Gx interface to connect to a specific PCRF for a range of subscribers configure msisdn-prefix-from <msisdn_prefix_from> and
msisdn-prefix-to <msisdn_prefix_to> with the starting and ending MSISDNs respectively.
To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both msisdn-prefix-from <msisdn_prefix_from> and
msisdn-prefix-to <msisdn_prefix_to> with the same MSISDN.
|
•
|
Optional: To configure the Quality of Service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
|
qos-update-timeout <timeout_duration>
|
•
|
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
|
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
|
•
|
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
|
charging-action <charging_action_name>
|
•
|
<context_name> must be the name of the context in which the IMS Authorization service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication in the context.
|
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication.
action priority <priority> dynamic-only ruledef <ruledef_name> charging-action <charging_action_name> monitoring-key <monitoring_key>
|
•
|
The event-update CLI which enables volume usage report to be sent in event updates is available only in 10.2 and later releases. The optional keyword reset-usage enables to support delta reporting wherein the usage is reported and reset at PCEF. If this option is not configured, the behavior is to send the usage information as part of event update but not reset at PCEF.
|
Important: Unconditional reporting of event triggers from PCRF to PCEF when PCEF has not requested for is not supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, only the AN_GW_CHANGE (21) event trigger is supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, only authorized IP-CAN Session is supported. Provisioning of authorized QoS per IP-CAN bearer, policy enforcement for authorized QoS per QCI, and coordination of authorized QoS scopes in mixed mode are not applicable.
Important: In the HA/PDSN Rel. 8 Gx implementation, offline charging is not supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Important: A third kind of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
Important: Configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <primary_host_name> [ realm <primary_realm_id> ] [ secondary host <secondary_host_name> [ realm <secondary_realm_id> ] ] [ -noconfirm ]
peer <primary_peer_name> [ realm <primary_realm_name> ] address <ip_address> [ port <port_number> ]
peer <secondary_peer_name> [ realm <secondary_realm_name> ] address <ip_address> [ port <port_number> ]
|
•
|
<context_name> must be the name of the context where you want to enable IMSA service.
|
|
•
|
<imsa_service_name> must be the name of the IMSA service to be configured for Rel. 8 Gx interface authentication.
|
|
•
|
<context_name> must be the name of the context in which the IMSA service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication in the context.
|
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Important: Online charging for events (“Immediate Event Charging” and “Event Charging with Reservation”) is not supported. Only “Session Charging with Reservation” is supported.
Important: Decentralized Rating is not supported in this release. Decentralized Unit determination is done using CLI configuration.
Important: Immediate Event Charging is not supported in this release. “Reserve Units Request” and “Reserve Units Response” are done for Session Charging and not for Event Charging.
Important: Cost-Information, Remaining-Balance, and Low-Balance-Indication AVPs are not supported.
Important: Acct-Application-Id is not parsed and if sent will be ignored by the PCEF/GW. In case the Result-Code is not DIAMETER_SUCCESS, the connection to the peer is closed.
Important: DWR is sent only after Tw expiry after the last message that came from the server. Say if there is continuous exchange of messages between the peers, DWR might not be sent if (Current Time - Last message received time from server) is less than Tw.
Important: Restricting usages based on CC-Input-Octets and CC_Output-Octets is not supported in this release.
Important: In this release, Gy triggers are not supported for HA.
Important: In this release, Gy does not support UNIT_INDETERMINATE value.
Important: FUI AVP at command level is only supported for Terminate action.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
peer <peer> realm <realm> address <ip_address>
peer <peer> realm <realm> address <ip_address>
action priority <action_priority> ruledef <ruledef_name> charging-action <charging_action_name>
For information on installing and verifying licenses, refer to the Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to
CFSG Configuration Mode Commands chapter in Command
Line Interface Reference.
context <icap_ctxt_name> [ -noconfirm ]
icap server <ip_address> [port <port_number>][max <max_msgs>][priority <priority>]
|
•
|
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
|
|
•
|
In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.
|
|
•
|
In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.
|
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
Important: The IP Security is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
Caution: IPSec parameter configurations saved using this release may not function properly with older software releases.
|
•
|
PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. This application can be implemented for both core network service and HA-based systems. The following figure shows IPSec configurations.
|
|
•
|
Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.
|
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
|
•
|
L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.
|
As described in the IP Access Control Lists chapter of this guide, ACLs on the system define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
Important: These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
Important: These instructions assume that the systems were previously configured to support subscriber data sessions either as an FA or an HA.
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.
Important: These instructions assume that the system was previously configured to support subscriber data sessions and L2TP tunneling either as a PDSN or an HA. In addition, with the exception of subscriber attributes, all other parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Important: These instructions assume that the system was previously configured to support PDSN compulsory tunneling subscriber data sessions. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Important: These instructions assume that the system was previously configured to support subscriber PDP contexts and L2TP tunneling either as a GGSN. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Important: This section provides the minimum instruction set for configuring transform set on your system. For more information on commands that configure additional parameters and options, refer to the
Context Configuration Mode Commands and
Crypto Transform Configuration Mode chapters in the Command
Line Interface Reference.
crypto ipsec transform-set <
transform_name>
ah hmac {
md5-96 |
none |
sha1-96 }
esp hmac { {
md5-96 |
none |
sha1-96 } {
cipher {
des-cbc |
3des-cbc |
aes-cbc } |
none }
mode {
transport |
tunnel }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the crypto transform set(s).
|
|
•
|
<transform_name> is the name of the crypto transform set in the current context that you want to configure for IPSec configuration.
|
Important: This section provides the minimum instruction set for configuring ISAKMP policies on the system. For more information on commands that configure additional parameters and options, refer to the
Context Configuration Mode Commands and
ISAKMP Configuration Mode Commands chapters in the Command
Line Interface Reference.
encryption {
3des-cbc |
des-cbc }
group {
1 |
2 |
3 |
4 |
5 }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP policy.
|
|
•
|
<priority> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.
|
show crypto isakmp policy priority
Caution: Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the
clear crypto security-association command located in the
Exec Mode Commands chapter of the Command
Line Interface Reference for more information.
Important: This section provides the minimum instruction set for configuring ISAKMP crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the
Context Configuration Mode Commands and
Crypto Map ISAKMP Configuration Mode chapters in the Command
Line Interface Reference.
crypto map <
map_name>
ipsec-isakmp
set isakmp preshared-key <
isakmp_key>
set mode {
aggressive |
main }
set pfs {
group1 |
group2 |
group5 }
set transform-set <
transform_name>
match address <
acl_name> [
preference ]
match crypto-group <
group_name> {
primary |
secondary }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
|
|
•
|
<map_name> is name by which the ISAKMP crypto map will be recognized by the system.
|
|
•
|
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter. For more information, refer to the Redundant IPSec Tunnel Fail-Over section of this chapter.
|
Caution: Modification(s) to an existing ISAKMP crypto map configuration will not take effect until the related security association has been cleared. Refer to the
clear crypto security-association command located in the
Exec Mode Commands chapter of the Command
Line Interface Reference for more information.
Important: This section provides the minimum instruction set for configuring dynamic crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the
Context Configuration Mode Commands and
Crypto Map Dynamic Configuration Mode chapters in the Command
Line Interface Reference.
crypto map <
map_name>
ipsec-dynamic
set pfs {
group1 |
group2 |
group5 }
set transform-set <
transform_name>
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the dynamic crypto maps.
|
|
•
|
<map_name> is name by which the dynamic crypto map will be recognized by the system.
|
Caution: Modification(s) to an existing dynamic crypto map configuration will not take effect until the related security association has been cleared. Refer to the
clear crypto security-association command located in the
Exec Mode Commands chapter of the Command
Line Interface Reference for more information.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
Important: This section provides the minimum instruction set for configuring manual crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the
Context Configuration Mode Commands and
Crypto Map Manual Configuration Mode chapters in the Command
Line Interface Reference.
crypto map <
map_name>
ipsec-manual
match address <
acl_name> [
preference ]
set transform-set <
transform_name>
set session-key {
inbound |
outbound } {
ah <
ah_spi> [
encrypted ]
key <
ah_key> |
esp <
esp_spi> [
encrypted ]
cipher <
encryption_key> [
encrypted ]
authenticator <
auth_key> }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the manual crypto maps.
|
|
•
|
<map_name> is name by which the manual crypto map will be recognized by the system.
|
|
•
|
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter.
|
Caution: Modification(s) to an existing manual crypto map configuration will not take effect until the related security association has been cleared. Refer to the
clear crypto security-association command located in the
Exec Mode Commands chapter of the Command
Line Interface Reference for more information.
Important: This section provides the minimum instruction set for applying manual or ISAKMP crypto maps to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference.
interface <
interface_name>
|
•
|
<ctxt_name> is the system context in which the interface is configured to apply crypto map.
|
|
•
|
<interface_name> is the name of a specific interface configured in the context to which the crypto map will be applied.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
|
show configuration context ctxt_name | grep interface
Important: This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference.
isakmp peer-ha <
ha_address>
crypto-map <
map_name> [
secret <
preshared_secret> ]
isakmp default crypto-map <
map_name> [
secret <
preshared_secret> ]
|
•
|
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
|
|
•
|
<fa_svc_name> is name of the FA service for which you are configuring IPSec.
|
|
•
|
<ha_address> is IP address of the HA service to which FA service will communicate on IPSec.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
|
show fa-service {
name service_name |
all }
Important: This section provides the minimum instruction set for configuring an HA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference.
isakmp aaa-context <
aaa_ctxt_name>
isakmp peer-fa <
fa_address> crypto-map <
map_name> [
secret <
preshared_secret> ]
|
•
|
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
|
|
•
|
<ha_svc_name> is name of the HA service for which you are configuring IPSec.
|
|
•
|
<fa_address> is IP address of the FA service to which HA service will communicate on IPSec.
|
|
•
|
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
|
show ha-service {
name service_name |
all }
As described in the How the IPSec-based Mobile IP Configuration Works section of this chapter, the system uses attributes stored in a subscriber’s RADIUS profile to determine how IPSec should be implemented.
|
|
|
|
|
|
|
3 : Enables IPSec for tunnels and registration messages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Important: These instructions are required for compulsory tunneling. They should only be performed for attribute-based tunneling if the Tunnel-Service-Endpoint, the SN1-Tunnel-ISAKMP-Crypto-Map, or the SN1 -Tunnel-ISAKMP-Secret are not configured in the subscriber profile.
Important: This section provides the minimum instruction set for configuring an LAC service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference.
lac-service <
lac_svc_name>
peer-lns <
ip_address> [
encrypted]
secret <
secret> [
crypto-map <
map_name> { [
encrypted]
isakmp-secret <
secret> } ] [
description <
text> ] [
preference <
integer>]
isakmp aaa-context <
aaa_ctxt_name>
|
•
|
<ctxt_name> is the destination context where the LAC service is configured to support IPSec.
|
|
•
|
<lac_svc_name> is name of the LAC service for which you are configuring IPSec.
|
|
•
|
<lns_address> is IP address of the LNS node to which LAC service will communicate on IPSec.
|
|
•
|
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
|
show lac-service nameservice_name
In addition to the subscriber profile attributes listed in the RADIUS and Subscriber Profile Attributes Used section of the
L2TP Access Concentrator chapter in this guide, the table below lists the attributes required to support IPSec for use with attribute-based L2TP tunneling.
|
•
|
<ctxt_name> is the destination context where the PDSN service is configured.
|
|
•
|
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
|
|
•
|
<lac_ctxt_name> is the name of the destination context where the LAC service is located.
|
pdsn-service <
pdsn_svc_name>
ppp tunnel-context <
lac_ctxt_name>
|
•
|
<ctxt_name> is the destination context where the PDSN service is configured.
|
|
•
|
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
|
|
•
|
<lac_ctxt_name> is name of the destination context where the LAC service is located.
|
show pdsn-service name service_name
Important: The peer security gateway must support RFC 3706 in order for this functionality to function properly.
|
•
|
Fail-over successful: The switchover of user traffic was successful. This is generated for both primary-to-secondary and secondary-to-primary switchovers.
|
|
•
|
Unsuccessful fail-over: An error occurred when switching user traffic from either the primary to secondary tunnel or the secondary to primary tunnel.
|
Important: Parameters configured using this procedure must be configured in the same context on the system.
Important: The system supports a maximum of 32 crypto groups per context. However, configuring crypto groups to use the same loopback interface for secondary IPSec tunnels is not recommended and may compromise redundancy on the chassis.
Important: This section provides the minimum instruction set for configuring crypto groups on the system. For more information on commands that configure additional parameters and options, refer Command Line Interface Reference.
ikev1 keepalive dpd interval <
dur> timeout <
dur>
num-retry <
retries>
crypto-group <
group_name>
match address <
acl_name> [ <
preference> ]
switchover auto [
do-not-revert ]
|
•
|
<ctxt_name> is the destination context where the Crypto Group is to be configured.
|
|
•
|
<group_name> is name of the Crypto group you want to configure for IPSec tunnel failover support.
|
|
•
|
<acl_name> is name of the pre-configured crypto ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. For more information on crypto ACL, refer Crypto Access Control List (ACL) section of this chapter.
|
crypto map <
map_name1>
ipsec-isakmp
match crypto-group <
group_name>
primary
crypto map <
map_name>
ipsec-isakmp
match crypto-group <
group_name>
secondary
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.
|
|
•
|
<map_name1> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.
|
|
•
|
<map_name2> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.
|
show crypto group [
summary |
name group_name ]
DPD is configured at the context level and is used in support of the IPSec Tunnel Failover feature (refer to the Redundant IPSec Tunnel Fail-Over section) and/or to help prevent tunnel state mismatches between an FA and HA when IPSec is used for Mobile IP applications. When used with Mobile IP applications, DPD ensures the availability of tunnels between the FA and HA. (Note that the starIPSECDynTunUp and starIPSECDynTunDown SNMP traps are triggered to indicate tunnel state for the Mobile IP scenario.)
Important: If DPD is enabled while IPSec tunnels are up, it will not take affect until all of the tunnels are cleared.
Important: DPD must be configured in the same context on the system as other IPSec Parameters.
ikev1 keepalive dpd interval <
dur>
timeout <
dur>
num-retry <
retries>
|
•
|
<ctxt_name> is the destination context where the Crypto Group is to be configured.
|
Important: This section provides the minimum instruction set for configuring an APN template to support L2TP for APN. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference. To configure the APN to support L2TP:
tunnel l2tp [
peer-address <
lns_address> [ [
encrypted ]
secret <
l2tp_secret> ] [
preference <
num> ] [
tunnel-context <
tunnel_ctxt_name> ] [
local-address <
agw_ip_address> ] [
crypto-map <
map_name> { [
encrypted ]
isakmp-secret <
crypto_secret> } ]
|
•
|
<ctxt_name> is the system context in which the APN template is configured.
|
|
•
|
<apn_name> is name of the preconfigured APN template in which you want to configure L2TP support.
|
|
•
|
<lns_address> is IP address of the LNS node to which this APN will communicate.
|
|
•
|
<tunnel_ctxt_name> is the L2TP context in which the L2TP tunnel is configured.
|
|
•
|
<agw_ip_address> is the local IP address of the GGSN in which this APN template is configured.
|
|
•
|
<map_name> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.
|
|
•
|
PSK (Pre-Shared Key) Authentication: A pre-shared key is a shared secret that was previously shared between two network nodes. IPSec for LTE/SAE supports PSK such that both IPSec nodes must be configured to use the same shared secret.
|
|
•
|
Idle Tunnel Termination: When a session manager for a service detects that all subscriber sessions using a given IPSec tunnel have terminated, the IPSec tunnel also gets terminated after a timeout period.
|
|
•
|
Service Termination: When a service running on a network node is brought down for any reason, all corresponding IPSec tunnels get terminated. This may be caused by the interface for a service going down, a service being stopped manually, or a task handling an IPSec tunnel restarting.
|
|
•
|
Unreachable Peer: If a network node detects an unreachable peer via Dead Peer Detection (DPD), the IPSec tunnel between the nodes gets terminated. DPD can be enabled per P-GW, S-GW, and MME service via the system CLI during crypto template configuration.
|
|
•
|
E-UTRAN Handover Handling: Any IPSec tunnel that becomes unusable due to an E-UTRAN network handover gets terminated, while the network node to which the session is handed initiates a new IPSec tunnel for the session.
|
Important: The L2TP Access Concentrator is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
Important: The LAC service uses UDP ports 13660 through 13668 as the source port for sending packets to the LNS.
|
•
|
Attribute-based tunneling: This method is used to encapsulate PPP packets for only specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
|
|
•
|
PDSN Service-based compulsory tunneling: This method of tunneling is used to encapsulate all incoming PPP traffic from the R-P interface coming into a PDSN service, and tunnel it to an LNS peer for authentication. It should be noted that this method does not consider subscriber configurations, since all authentication is performed by the peer LNS.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
|
2.
|
The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
|
•
|
Transparent IP: The APN template’s L2TP parameter settings will be applied to the session.
|
|
•
|
Non-transparent IP: Since authentication is required, L2TP parameter attributes in the subscriber profile (if configured) will take precedence over the settings in the APN template.
|
|
•
|
PPP: The APN template’s L2TP parameter settings will be applied and all of the subscriber’s PPP packets will be forwarded to the specified LNS.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a GGSN or P-GW.
Important: L2TP tunneling can be configured within individual subscriber profiles as opposed/or in addition to configuring support with an APN template. Subscriber profile configuration is described in the
Configuring Subscriber Profiles for L2TP Support section of this chapter.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as an HA.
Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Important: If the LAC service and egress interface are configured in the same context as the core service or HA service, this attribute is not needed.
|
|
|
|
|
Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized.
|
|
|
|
|
|
|
•
|
Random - Random LNS selection order, the Tunnel-Preference attribute is not used in determining which LNS to select.
|
|
•
|
Balanced - LNS selection is sequential balancing the load across all configured LNS nodes, the Tunnel-Preference attribute is not used in determining which LNS to select.
|
|
•
|
Prioritized - LNS selection is made based on the priority assigned in the Tunnel-Preference attribute.
|
|
|
|
|
|
|
Important: The configuration of RADIUS-based subscriber profiles is not discussed in this document. Please refer to the documentation supplied with your RADIUS server for further information.
Important: This section provides the minimum instruction set for configuring local subscriber profile for L2TP support on the system. For more information on commands that configure additional parameters and options, refer to the
LAC Service Configuration Mode Commands chapter in the Command
Line Interface Reference.
tunnel l2tp peer-address <lns_ip_address> [ preference <
integer> | [ encrypted ] secret <
secret_string> | tunnel-context <
context_name> | local-address <
local_ip_address> }
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile.
|
|
•
|
<lns_ip_address> is the IP address of LNS server node and < local_ip_address> is the IP address of system which is bound to LAC service.
|
Important: Not all commands, keywords and functions may be available. Functionality is dependent on platform and license(s).
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer to the
LAC Service Configuration Mode Commands chapter in the Command
Line Interface Reference.
|
Step 2
|
Optional. Configure LNS peer information if the Tunnel-Service-Endpoint attribute is not configured in the subscriber profile or PDSN compulsory tunneling is supported by applying the example configuration in the Configuring LNS Peer section.
|
|
•
|
<dst_ctxt_name> is the destination context where you want to configure the LAC service.
|
peer-lns <ip_address> [encrypted] secret <
secret> [crypto-map <
map_name> {[encrypted] isakmp-secret <
secret> }] [description <
text>] [ preference <
integer>]
|
•
|
<dst_ctxt_name> is the destination context where the LAC service is configured.
|
Important: This section provides the minimum instruction set for modifying PDSN service for L2TP support on the system. For more information on commands that configure additional parameters and options, refer to the
LAC Service Configuration Mode Commands chapter in the Command
Line Interface Reference.
|
•
|
<source_ctxt_name> is the name of the source context containing the PDSN service, which you want to modify for L2TP support.
|
|
•
|
<pdsn_service_name> is the name of the pre-configured PDSN service, which you want to modify for L2TP support.
|
|
•
|
<lac_context_name> is typically the destination context where the LAC service is configured.
|
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer to the
LAC Service Configuration Mode Commands chapter in the Command
Line Interface Reference.
tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <
l2tp_secret> ] [ preference <
integer> ] [ tunnel-context <
l2tp_context_name> ] [ local-address <
local_ip_address> ] [ crypto-map <
map_name> { [ encrypted ] isakmp-secret <
crypto_secret> } ]
|
•
|
<dst_ctxt_name> is the name of system destination context in which the APN is configured.
|
|
•
|
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
|
|
•
|
<lns_address> is the IP address of LNS server node and < local_ip_address> is the IP address of system which is bound to LAC service.
|
|
•
|
<dst_ctxt_name> is the destination context where APN template is is configured.
|
|
•
|
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
|
Important: This license is enabled by default; however, not all features are supported on all platforms and other licenses may be required for full functionality as described in this chapter.
Important: Registration Revocation functionality is also supported for Proxy Mobile IP. However, only the HA can initiate the revocation for Proxy-MIP calls.
Important: The Revocation Support Extension in the RRQ or RRP must be protected by the FA-HA Authentication Extension. Therefore, an FA-HA SPI must be configured at the FA and the HA for this to succeed.
|
•
|
FA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
|
|
•
|
HA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions for a core network service with FA and/or an HA according to the instructions described in the respective product Administration Guide.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
fa-service <
fa_service_name>
revocation max-retransmission <
number>
revocation retransmission-timeout <
time>
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the
System Administration Guide and the Command
Line Interface Reference.
ha-service <
ha_service_name>
revocation max-retransmission <
number>
revocation retransmission-timeout <
time>
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the
System Administration Guide and the Command
Line Interface Reference.
Important: Proxy Mobile IP is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
|
•
|
Scenario 1: The AAA server that authenticates the MN at the PDSN allocates an IP address to the MN. Note that the PDSN does not allocate an address from its IP pools.
|
|
•
|
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
|
|
•
|
Scenario 1: The AAA server that authenticates the MN at the ASN GW allocates an IP address to the MN. Note that the ASN GW does not allocate an address from its IP pools.
|
|
•
|
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
|
Important: For Proxy-MIP call setup using PAP, the first 14 steps are the same as for CHAP authentication. However, here they deviate because the MS does not support EAP-MD5 authentication, but EAP-GTC. In response to the EAP-MD5 challenge, the MS instead responds with legacy-Nak with EAP-GTC. The diagram below picks up at this point.
Important: Not all commands and keywords/variables may be supported. This depends on the platform type and the installed license(s).
|
•
|
FA service(s): Proxy Mobile IP must be enabled, operation parameters must be configured, and FA-HA security associations must be specified.
|
|
•
|
Subscriber profile(s): Attributes must be configured to allow the subscriber(s) to use Proxy Mobile IP. These attributes can be configured in subscriber profiles stored locally on the system or remotely on a RADIUS AAA server.
|
|
•
|
APN template(s): Proxy Mobile IP can be supported for every subscriber IP PDP context facilitated by a specific APN template based on the configuration of the APN.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a core network service and/or an HA according to the instructions described in the respective product administration guide.
fa-service <
fa_service_name>
proxy-mip max-retransmissions <
integer>
proxy-mip retransmission-timeout <
seconds>
proxy-mip renew-percent-time percentage
fa-ha-spi remote-address {
ha_ip_address |
ip_addr_mask_combo }
spi-number number {
encrypted secret enc_secret |
secret secret } [
description string ][
hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } | replay-protection { timestamp | nonce } | timestamp-tolerance tolerance ]
|
•
|
The proxy-mip max-retransmissions command configures the maximum number re-try attempts that the FA service is allowed to make when sending Proxy Mobile IP Registration Requests to the HA.
|
|
•
|
proxy-mip retransmission-timeout configures the maximum amount of time allowed by the FA for a response from the HA before re-sending a Proxy Mobile IP Registration Request message.
|
|
•
|
proxy-mip renew-percent-time configures the amount of time that must pass prior to the FA sending a Proxy Mobile IP Registration Renewal Request.
|
|
•
|
Use the fa-ha-spi remote-addresscommand to modify configured FA-HA SPIs to support Proxy Mobile IP. Refer to the Command Line Interface Reference for the full command syntax.
|
Important: Note that FA-HA SPIs
must be configured for the Proxy-MIP feature to work, while it is optional for regular MIP.
|
•
|
Use the authentication mn-ha allow-noauth command to configure the FA service to allow communications from the HA without authenticating the HA.
|
Proceed to the optional Configuring Proxy MIP HA Failover section to configure Proxy MIP HA Failover support or skip to the
Configuring HA Services section to configure HA service support for Proxy Mobile IP.
Important: This configuration in this section is optional.
fa-service <
fa_service_name>
proxy-mip ha-failover [
max-attempts <
max_attempts>
| num-attempts-before-switching <
num_attempts> |
timeout <
seconds> ]
ha-service <
ha_service_name>
Important: Note that FA-HA SPIs must be configured for the Proxy MIP feature to work while it is optional for regular MIP. Also note that the above syntax assumes that FA-HA SPIs were previously configured as part of the HA service as described in respective product Administration Guide. The
replay-protection and
timestamp- tolerance keywords should only be configured when supporting Proxy Mobile IP.
fa-ha-spi remote-address <
fa_ip_address>
spi-number <
number> {
encrypted secret <
enc_secret> |
secret <
secret> } [
description <
string> ] [
hash-algorithm {
hmac-md5 | md5 | rfc2002-md5 } ]
replay-protection {
timestamp | nonce } |
timestamp-tolerance <
tolerance> ]
show ha-service name <
ha_service_name>
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
|
|
|
|
|
|
|
|
|
|
This attribute must be enabled to support Proxy Mobile IP.
|
|
•
|
Disabled - do not perform compulsory Proxy-MIP (0)
|
|
•
|
Enabled - perform compulsory Proxy-MIP (1)
|
|
|
|
Important: Regardless of the configuration of this attribute, the FA facilitating the Proxy Mobile IP session will not allow simultaneous Simple IP and Mobile IP sessions for the MN.
|
|
|
|
|
|
|
|
|
|
subscriber name <
subscriber_name>
mobile-ip home-agent <
ha_address>
<optional> mobile-ip home-agent <
ha_address>
alternate
ip context-name <
context_name>
subscriber name <
subscriber_name>
subscriber_name is the name of the subscriber and can be from 1 to 127 alpha and/or numeric characters and is case sensitive.
ip context-name <
context_name>
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the
System Administration Guide and the Command
Line Interface Reference.
Important: This is an optional configuration. In addition, attributes returned from the subscriber’s profile for non-transparent IP PDP contexts take precedence over the configuration of the APN.
context_name is the name of the system destination context designated for APN configuration. The name must be from 1 to 79 alpha and/or numeric characters and is case sensitive.The following prompt appears:
[<context_name>]
host_name(config-ctx)#
apn_name is the name of the APN that is being configured. The name must be from 1 to 62 alpha and/or numeric characters and is not case sensitive. It may also contain dots (.) and/or dashes (-).The following prompt appears:
[<context_name>]
host_name(config-apn)#
|
Step 5
|
Optional. GGSN/FA MN-NAI extension can be skipped in MIP Registration Request by entering following command:
|
|
Step 7
|
Repeat step 1 through step 6 as needed to configure additional APNs.
|
Important: Traffic Policing and Shaping is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the
Managing License Keys section of the
Software Management Operations chapter in the
System Administration Guide.
|
•
|
Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets can be transmitted/received for the subscriber during the sampling interval.
|
|
•
|
Peak Data Rate (PDR): The maximum rate (in bits per second) that subscriber packets can be transmitted/received for the subscriber during the sampling interval.
|
|
•
|
Burst-size: The maximum number of bytes that can be transmitted/received for the subscriber during the sampling interval for both committed (CBS) and peak (PBS) rate conditions. This represents the maximum number of tokens that can be placed in the subscriber’s “bucket”. Note that the committed burst size (CBS) equals the peak burst size (PBS) for each subscriber.
|
|
•
|
Drop: The offending packet is discarded.
|
|
•
|
Lower the IP Precedence: The packet’s ToS bit is set to “0”, thus downgrading it to Best Effort, prior to passing the packet. Note that if the packet’s ToS bit was already set to “0”, this action is equivalent to “Transmit”.
|
Important: In 3GPP service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the
ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the
ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.
|
•
|
Optionally, configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
|
Important: If a “subscribed” traffic class is received, the system changes the class to background and sets the following: The uplink and downlink guaranteed data rates are set to 0. If the received uplink or downlink data rates are 0 and traffic policing is disabled, the default of 64 kbps is used. When enabled, the APN configured values are used. If the configured value for downlink max data rate is larger than can fit in an R4 QoS profile, the default of 64 kbps is used. If either the received uplink or downlink max data rates is non-zero, traffic policing is employed if enabled for the background class. The received values are used for responses when traffic policing is disabled.
Important: In 3GPP, service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command
Line Interface Reference for complete information regarding all commands.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the
ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the
ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.
|
Step 2
|
Optional. Configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
|
|
•
|
If the exceed/violate action is set to lower-ip-precedence, this command may override the configuration of the ip qos-dscp command in the GGSN service configuration mode for packets from the GGSN to the SGSN. In addition, the GGSN service ip qos-dscp command configuration can override the APN setting for packets from the GGSN to the Internet. Therefore, it is recommended that command not be used in conjunction with this action.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
|
|
|
|
|
|
|
ip route <ip_addr/ip_mask> <
next_hop_addr> <
lcl_cntxt_intrfc_name>
ipv6 route <ipv6_addr/prefix> next-hop <
sgw_addr> interface <
pgw_sgw_intrfc_name>
ip pool <name> range <
start_address end_address> public <
priority>
ipv6 pool <name> range <
start_address end_address> public <
priority>
peer <gx_cfg_name> realm <
name> address <
pcrf_ip_addr>
peer <gy_cfg_name> realm <
name> address <
ocs_ip_addr>
peer <rf_cfg_name> realm <
name> address <
ofcs_ip_addr>
ip route <ip_addr/ip_mask> <
next_hop_addr> <
lcl_cntxt_intrfc_name>
ipv6 route <ipv6_addr/prefix> next-hop <
sgw_addr> interface <
pgw_sgw_intrfc_name>
ip pool <name> range <
start_address end_address> public <
priority>
ipv6 pool <name> range <
start_address end_address> public <
priority>
peer <gx_cfg_name> realm <
name> address <
pcrf_ip_addr>
peer <gy_cfg_name> realm <
name> address <
ocs_ip_addr>
peer <s6b_cfg_name> realm <
name> address <
3gpp_aaa_ip_addr>
peer <rf_cfg_name> realm <
name> address <
ofcs_ip_addr>
Caution: Large numbers of services greatly increase the complexity of management and may impact overall system performance (i.e. resulting from such things as system handoffs). Therefore, it is recommended that a large number of services only be configured if your application absolutely requires it. Please contact your local service representative for more information.